tail-call-optimisation

[Simon Harris]

Does rubinius perform any kind of TOC or are there any plans?

[evanphx]

Hi Simon,

On Dec 24, 2:19 am, Simon Harris <haruki.zae...@gmail.com> wrote:
> Does rubinius perform any kind of TOC or are there any plans?

We currently do not do any tail call optimizations. One big reason is
that tail call optimizations typically destroy proper backtrace
information. I consider that an unacceptable side-effect for any kind
of automatic tail call detection.

I might consider some explicit tail call tagging, where the user
understands that using it means confusing backtraces.

A simple syntax like:

return Rubinius.tailcall obj.method(....)

would maybe be acceptable.

- Evan

[Simon Harris]

I understand the rationale but explicit TOC is, IMHO, nasty. How about
a VM-wide switch instead? Then I've made it explicit that I accept the
consequences of the optimisation. I can then develop on the small
without TOC and execute on the large with it. It also means the code
is technically portable to other implementations.

Of course were an explicit call required, I'd probably use it anyway
and implement it on other platforms as a stub :/

[Kevin Clark]

Maybe a '-O' makes sense in general for optimizations that are going
to make debugging ugly?

--
Kevin Clark
http://glu.ttono.us

[Simon Harris]

+1

[Simon Harris]

On Dec 25, 3:21 am, evanphx <evanw...@gmail.com> wrote:
>

> A simple syntax like:
>
>   return Rubinius.tailcall obj.method(....)
>

If having an explicit method would speed acceptance, I'd be happy to
compromise :)

Is this something I could do in Ruby or will it require C++? The
former I can have a go at; the latter not so much :/